FE와 BE의 연결

Projects · 2025-09-04

html 테스트

Projects · 2025-07-26

nnUNet 서비스 구현

개요 목적 nnUNet 서비스의 내부 기능을 구현한다. 문제 상황 Cleancode 설계 원칙에 따라, 각 모듈을 분리하려 했으나, 분리에 기준을 명확하게 정하고, 이를 기록할 필요성이 느껴졌다. I/O 기능을 분리하여 단일책임 원칙 준수 I/O 기능이 Feature 추출, TotalSegmentator 기능 등에 결합되어 경로 -> 실행 구조를 따르고 있다. 해당 구조를 수정하지 않으면 한번에 I/O 각 기능에 실행이 아닌, 각 기능을 실행할 때마다 I/O가 실행되어야 하는 불편함이 따른다. 각 모듈의 가독성과, 유지/보수성 증가를 위한 Clean Code를 어떻게 설계해야하는가. 단일책임 원칙 준수, 의존성 주입, 인터페이스 통일에 원칙을 준수하여 코드를 설계 그러나 이러한 원칙에 따라 코드를 분류할 때 어떤 코드를 같은 파일에 어떤 코드를 일반화시킨 I/O 등의 모듈에 넣어야할지 기준의 모호함이 발생 해당 모호함을 코드 변경 사유에 따라 정리하기 위해 각 코드들의 목적에 대한 정리가 필요. 결국 핵심은 현재 서비스를 만들 때 각 모듈 단위의 추상화를 통해서, 인터페이스를 이해하기 쉽게 정리하고, 교체를 용이하게 만드는 것 변경의 이유를 분리하라 (SRP) 같이 바뀌는 것끼리 묶고, 따로 바뀌는 건 나눈다. 변경 이유가 다른데 같이 묶으면 나중에 다 같이 바뀌는 지옥이 됨 인터페이스는 용도 기준으로 만들라 데이터의 타입이 아니라, 역할과 목적을 기준으로 묶어야 함 ❌ 잘못된 추상화 ✅ 올바른 추상화 “이미지와 관련된 걸 ImageUtils에 다 넣자” “AI 모델의 입력 생성 → FeatureExtractor” 구체적인 것이 아니라, 의도를 표현하라 함수/클래스명, 모듈명은 무엇을 한다가 아니라 왜 한다를 표현 ❌ 잘못된 추상화 ✅ 올바른 추상화 load_image, save_image, sitk2nib DataAdapter (형식 변환의 책임) make_ap_image, extract_mask FeatureBuilder (모델 입력 생성의 책임) 추상화는 실제 사용 사례를 최소 2개 생각하고 하라 “지금 하나만 있을 때는 절대 추상화하지 마라” → 재사용 포인트가 최소 2개 이상일 때 추상화가 필요 하나만 있을 때 수행하는 추상화는 다른 재사용 포인트가 생길 때 문제가 될 확률이 높다(기존의 것에 맞춰져 있을 확률이 높기 때문) 인터페이스는 “최소한의 정보만 넘기도록” 함수에 다 때려 넣음 나중에 바꾸기 힘듦 → 필요한 최소한의 데이터만 넘기고, 의도를 명확히 모듈을 리팩토링할 떄 원칙을 정하자! 원칙 재사용되는 코드는 무조건 분리하기! 각 인터페이스가 최소의 정보만으로 통신이 가능하게! 조금 비효율적이더라도 일관된 구조로 통신이 가능하게! 코드가 확장이 편하도록, 전략 패턴, 어댑터 패턴 등을 적용하기! 각 모듈별로 실제 실행이 되는 usecase 부분을 각각 작성해두고, 전체 모듈의 usecase를 조립하는 pipeline 파일과, 이를 api와 연결하는 entrypoint 설계 “핵심은 코드가 어떤 식으로 수정될 수 있을까를 예상하고, 수정이 편하도록 관리하는 것이다.” 이를 위한 기능의 정리 현재 nnUNet 서비스에 존재하는 모든 기능을 정리 기능 설명 수정 가능 시나리오 일관성 제한 gRPC 통신 gRPC를 통해 API Gateway와 통신을 수행 API Gateway와 추가적인 통신 명령이 생기거나, 제거될 수 있음 case_dir만을 사용해 통신이 수행되야한다. nnUNet 추론 이미지를 입력받아 Clean Code를 위한 코드의 정리 각 코드가 담당하는 계층의 분리 코드를 추상화하는 목적에는 나중에 해당 코드를 재사용하고 읽기 편하게 만드려는 목적

Projects · 2025-07-14

결산

Projects · 2025-07-12

연구 기능 통합

개요 목적 Docker Container로 백엔드 내에서 nnUNet을 활용하는 연구 프로젝트 서비스를 완전히 분할하고, Image를 활용하는 부분은 하나로, 나머지 기능은 각각 배포환경을 다르게 구성하여, microservice처럼 각 기능을 연결한 프로젝트 제작하기 요구조건 nnUNet의 .nii.gz 데이터를 ndarray + props(nnUNet을 코드 상에서 실행하기 위한 또 다른 입력값)으로 추출해주는 SitkIO 함수를 활용해 I/O 횟수를 최소화(각 모델들을 한번의 I/O로 모두 실행가능하게) 메모리 소모량을 감소시키기 위해 각 알고리즘 실행 과정 속, 필요로 하는 최소값의 해상도로 알고리즘 수행 향후 다른 연구의 결합에 대한 유지/보수성 증가를 위해 CT Image를 직접적으로 활용하지 않는 다른 기능들은 따로 수행될 수 있도록 구성 구체화 Service Index Detail nnUNet 1 혈관, 요관, 구 버전 신장/종양, 구 버전 요관을 모델 별로 함수를 나누어 ndarray -> ndarray 구조로 각각 실행될 수 있도록 모듈화 nnUNet 2 조건에 따라 모델을 선택해, 해당 함수가 실행될 수 있도록 구조화 및 입출력 구조 요구조건 달성 (optional) nnUNet 3 빠르게 샘플을 만드는 기능을 추가, 만약 이를 추가할 거라면, 해당 서비스와 nnUNet 서비스가 병렬적으로 실행되고, obj 파일을 연속해서 업로드가 수행되야함 Smoothing 1 .nii.gz mask -> obj 파일로 만드는 업데이트된 기능(FE에 기능을 활용하기 위해선 해당 로직에 업데이트가 필요) post-processing 1 인공지능 inference 결과와, mask 결과를 활용하여 Fat mask를 추가해주는 기능 (optional) post-processing 2 nnUNet의 기능을 후처리 작업을 통해 보정해주는 역할 API Gateway 1 nnUNet 관련 기능, Smoothing 관련 기능, post-processing 관련 기능을 각각 container로 나누어 이를 연결해주는 역할 발견된 문제 1. 서비스에 분할에 관하여 마이크로 서비스로 얻고 싶었던 이점은 아래와 같았다. 1. 각 연구자들의 새로운 연구결과를 결합할 때 도커로 배포만 가능하면, monolithic에 결합하는 수고 없이, 통신으로 이를 해결 2. 각 연구자들의 연구 결과를 분리함으로써 다양한 라이브러리 사용되는 배포환경의 충돌 방지 그러나 현재의 백엔드 시스템은 연구자들이 주로 사용하는 nnUNet이라는 AI 아키텍쳐를 활용할 때 용량이 큰 의료이미지의 I/O 병목을 줄이기 위하여 , 해당 파일을 한번 불러오고, 저장 없이 전처리, AI inference, 후처리를 수행한 후 최종 결과만을 저장하여, 이를 활용한다. 이를 구현하기 위해선 각 서비스별로 I/O를 수행하지 않고, 모든 연구결과를 활용하기 위해서는 해당 서비스가 monolithic하게 존재해야한다. 이는 현재 마이크로 서비스를 만드려는 목적과 상충하는 결과이다. 그렇기에 앞으로 마이크로 서비스를 제작할 때는, 데이터 크기가 큰 의료이미지의 특성에 따라 발생하는 아래와 같은 문제를 고려해야한다. 1. 의료 '이미지'는 용량이 매우 크기에 I/O 병목이 존재하며, gRPC로 이미지 자체를 넘기는 것은 비효율적이다. 2. 여러 서비스가 각각 이미지를 병렬적으로 로드하고 처리한다면, 이에 따른 메모리 소모량을 고려해야한다. 3. 각 연구는 다양한 라이브러리를 사용하기에 이를 하나의 배포환경에 합쳐버리면, 유지/보수 및 안정성이 상당히 떨어진다. 이러한 문제를 해결하기 위한 아이디어는, 몇몇 서비스들은 의료이미지를 필수로 활용하진 않는 것이다. mask 데이터는 의료 이미지 데이터에 비해 훨씬 용량이 작으며, 이에 대한 I/O를 수행하는 것은 이미지에 비해 훨씬 작업 소모량이 적다. 그렇기에 이미지를 다루는 연구 결과물들은 성능 최적화를 위해 monolithic하게 수행할 수도 있겠지만, mask에 대한 처리를 수행하는 로직들에 대해서는 서비스를 나누는 것을 고려할 수 있다. 속도의 향상과 유지/보수성의 tradeoff를 고려하여 문제를 해결할 방법이 필요하다.

Projects · 2025-07-10

Service:nnUNet 개발

개요 목적 nnUNet과 torch를 사용하는 각 연구 성과를 통합한 nnUNet 서비스의 개발 요구조건 nnUNet의 .nii.gz 데이터를 ndarray + props(nnUNet을 코드 상에서 실행하기 위한 또 다른 입력값)으로 추출해주는 SitkIO 함수를 활용해 I/O 횟수를 최소화(각 모델들을 한번의 I/O로 모두 실행가능하게) 메모리 소모량을 감소시키기 위해 각 알고리즘 실행 과정 속, 필요로 하는 최소값의 해상도로 알고리즘 수행 각각의 Container에 그냥 OS를 활용하는 이미지를 쓰지말고, Container의 용량을 감소시키는 작은 이미지를 활용할 것 3차 회의 요구사항 백엔드 개발자와 기존의 nnUNet 기능만을 통합하는 과정이 아닌, Smoothing, PostProcessing 기능 까지 고려하는 2번째 시스템 개발에 관하여 회의를 진행 마이크로 서비스를 수행할 때 Docker Image 경량화에 대한 이슈 이미지가 무거우면 빌드 시간, 배포 시간, 디스크 사용량, 네트워크 트래픽 모두 증가함. 각 Pod이 이미지 Pull을 할 때 용량이 작을수록 빠르고 안정적. smoothing, post-processing 서비스를 분리하면서 다른 기능들은 mask에 한정해서는 I/O가 필요하고, 기존의 저장되던 Segmentation 이외의 다른 정보를 저장할 필요성이 대두 해당 사항에 대해 TotalSegmenatator 혹은 inference 결과 등을 mask 디렉토리에 저장하고 활용하는 것에 대해 문제가 없음을 확인 서비스 API Service EndPoint Parameter(request) Parameter(response) Detail Constraints nnUNet inference/totalseg image_path : str mask_path : str totalSegmentator를 실행시켜, 해당 이미지에 대한 Organ Mask를 저장하고, 저장한 Path를 반환 1mm보다 high resoulution을 가지는 이미지에 대해서는 더 나은 결과를 낼 수 없다 nnUNet inference/vessel image_A_path : str, image_P_path : str mask_path : str 2개 이미지의 파일 경로를 받아 image_A_path와 같은 물리적 공간을 가지는 신장,동맥,정맥 mask를 저장하고 해당 주소를 반환 A, P Phase에 해당하는 CT 이미지에 대해서만 유효한 결과를 낼 수 있다 nnUNet inference/ureter image_D_path : str mask_path : str 이미지 파일경로를 받아, 같은 물리적 공간을 가지는 요관, 신장 mask를 저장하고 해당 주소를 반환 D Phase .nii.gz에만 유효한 결과를 낼 수 있다 nnUNet inference/tumor image_path : str mask_path : str 이미지의 파일 경로를 받아, 같은 물리적 공간을 가지는 신장, 종양 mask를 저장하고 해당 주소를 반환 개발과정 DockerFile 작성 고려사항 현재 BE 시스템에서 기존에 사용하던 torch version = 2.2.2, cuda가 존재하여 GPU를 사용할 수 있어야 한다. totalsegmentator, nnunet이 사용 가능해야한다. gRPC 기반 api endpoint 설정 api service와 nnUNet에 해당하는 docker container 제작, 공유된 볼륨에 동일한 경로로 접근 가능한지 테스트 통신 담당 함수와, 각 통신 결과를 각 함수에 전달하는 entrypoint 함수 제작 현재 생각한 구조 각 서비스는 통신 함수를 main.py로 가지며, 해당 main.py와 동일한 디렉토리에 각 서비스가 구성된 라이브러리가 존재 각 라이브러리는 api에 따라 1:1로 실행되는 함수 entrypoint를 가지며, 이를 라이브러리 최상단에 위치 라이브러리 내부에서 각 함수에 따라 구동되는 기능별로 폴더를 구분하며, utils 폴더에 잡다한 기능들을 넣어두기 각 서비스 별로 통일된 라이브러리 선언 규칙이 필요 totalSegmentator 함수 제작 진행 과정 totalsegmenator 라이브러리 설치 => 발견된 문제, warning으로 현재 사용하고 있는 라이브러리 중 하나가 2025.12.30에 사라질 예정이라고 함, 오류가 발생했을 때 참고 totalsegmentator는 RAM, GPU 사용량이 필요함, 현재 docker ram 사용량이 MB단위임을 발견, totalsegmentator를 구동시키기 위해 20GB로 변경, 다만 서버 컴퓨터의 스펙은 로컬 개발환경과 다르게 128GB의 램을 보유하고 있으므로, 해당 Docker Container는 100GB정도까지 가도 괜찮을 듯 하다. totalsegmentator를 돌릴 시 멀티프로세싱을 사용하기 때문에 이를 gRPC와 함께 사용할 떄 fork관련 이슈가 발생, main 함수에 multiprocessing을 import해주고, 미리 조치를 취하면 괜찮지만 이게 왜 문제가 생기는지에 대한 고찰이 필요. 테스트 진행 완료 mask/total_A.nii.gz로 저장 밑 return이 잘 수행됨을 확인 API Gateway에서 inference/totalseg를 case 폴더 -> 각 이미지 폴더로 어떤 식으로 연결을 지어야할지에 대한 고찰이 필요 추후 체크리스트 BE->API Gateway와 inference/totalseg API에 대한 연결을 어떻게 수행할 것인가. 멀티 프로세싱 fork관련 이슈가 왜 발생하는가. nnUNet pth 파일 기반 교체 가능한 함수 개발 vessel Feature 추출 함수 개발

Projects · 2025-07-10

API 설계

Projects · 2025-07-10

nnUNet 관련 기능 분리

개요 목적 2차 회의를 수행하고, 해당 내용을 적용하기 위해 기능 구현을 구체화하여 구현하는 과정을 정리 구체화 gRPC를 활용하여 서로 다른 Docker Container간 str, List[str] 통신을 활용가능하고, 공유된 마운트 Volume에 동일한 Path로 접근가능하게 구현 Server를 아래 2가지 옵션으로 구현 각종 ai관련 기능을 모두 통합한 monolithic한 서비스 혈관, 요관, 신장 등 각각 기능들을 microservice로 분리하고, 모두 동일한 volume mount에서 경로만 통신해 통합된 기능을 제작 정해진 서버의 옵션에 따라 요구사항에 맞춘 Resize기능 각종 nnUNet 취사선택 기능 (optional) 빠른 샘플 제작 기능 을 구현할 수 있도록 수행한다. 개발일정 Date To Do Process ~07.09 gRPC를 통한 통신 구조 및 볼륨 마운트를 통해 동일한 파일 접근 가능한지 테스트 수행 완료(07.09~07.09) ~07.10 monolithic하게 구현할지, microservice로 구현할지 결정 진행(07.09~) ~07.13 nnUNet을 Path만 가지고 있으면, Phase에 따라 실행하는 구조 생성 ~07.14 optional한 기능의 구현가능성에 따라 추가 발견된 문제 1. 서비스에 분할에 관하여 마이크로 서비스로 얻고 싶었던 이점은 아래와 같았다. 1. 각 연구자들의 새로운 연구결과를 결합할 때 도커로 배포만 가능하면, monolithic에 결합하는 수고 없이, 통신으로 이를 해결 2. 각 연구자들의 연구 결과를 분리함으로써 다양한 라이브러리 사용되는 배포환경의 충돌 방지 그러나 현재의 백엔드 시스템은 연구자들이 주로 사용하는 nnUNet이라는 AI 아키텍쳐를 활용할 때 용량이 큰 의료이미지의 I/O 병목을 줄이기 위하여 , 해당 파일을 한번 불러오고, 저장 없이 전처리, AI inference, 후처리를 수행한 후 최종 결과만을 저장하여, 이를 활용한다. 이를 구현하기 위해선 각 서비스별로 I/O를 수행하지 않고, 모든 연구결과를 활용하기 위해서는 해당 서비스가 monolithic하게 존재해야한다. 이는 현재 마이크로 서비스를 만드려는 목적과 상충하는 결과이다. 그렇기에 앞으로 마이크로 서비스를 제작할 때는, 데이터 크기가 큰 의료이미지의 특성에 따라 발생하는 아래와 같은 문제를 고려해야한다. 1. 의료 '이미지'는 용량이 매우 크기에 I/O 병목이 존재하며, gRPC로 이미지 자체를 넘기는 것은 비효율적이다. 2. 여러 서비스가 각각 이미지를 병렬적으로 로드하고 처리한다면, 이에 따른 메모리 소모량을 고려해야한다. 3. 각 연구는 다양한 라이브러리를 사용하기에 이를 하나의 배포환경에 합쳐버리면, 유지/보수 및 안정성이 상당히 떨어진다. 이러한 문제를 해결하기 위한 아이디어는, 몇몇 서비스들은 의료이미지를 필수로 활용하진 않는 것이다. mask 데이터는 의료 이미지 데이터에 비해 훨씬 용량이 작으며, 이에 대한 I/O를 수행하는 것은 이미지에 비해 훨씬 작업 소모량이 적다. 그렇기에 이미지를 다루는 연구 결과물들은 성능 최적화를 위해 monolithic하게 수행할 수도 있겠지만, mask에 대한 처리를 수행하는 로직들에 대해서는 서비스를 나누는 것을 고려할 수 있다. 속도의 향상과 유지/보수성의 tradeoff를 고려하여 문제를 해결할 방법이 필요하다.

Projects · 2025-07-09

2차 회의 - 추가 요구사항 발생

추가 요구사항 현 진행상황 백엔드 서버를 구성하기 위해, 어떠한 백엔드 구성요소가 있고, 우리가 유지/보수, 최적화, 인수인계 가능성을 고려하여 어떠한 프레임워크들을 각 백엔드 구조에 활용할지 조사를 진행중 각 연구 프로젝트를 공유가 용이하기 위해 Docker로 구성을 변경 문제상황 백엔드 서버를 구성하기 위해, 어떤 프레임워크를 사용해야 하는가에 대한 조사를 수행하던 중, 2주 내로 각 연구의 결과물인 기능들을 통합하고, 하나의 제품으로 기능할 수 있도록하는 클라이언트의 요구사항이 발생 데드라인 이내에 해당 기능을 만들 수 있도록, 기존에 조사한 내용인 gRPC 기반의 microservice로 백엔드를 구성하는 인공지능 + 알고리즘 부분을 마이크로 서비스로 구현해, 기존의 백엔드와 연결되도록 만들 필요가 발생 해결방안 기존의 백엔드 담당자와 이 문제를 어떻게 해결할지 논의를 수행한 후 결론을 아래와 같이 내렸다. 기존의 백엔드는 아래와 같이 기능이 수행된다. 1, 2 Model(각각 담당하는 mask가 다르다.) N CT Image |--------| N mask A CT Image | | A mask ---> | Model | ---> P CT Image | | P mask D CT Image |________| D mask 그러나 현재의 ai 알고리즘은 퀄리티 좋은 결과를 위해 각각의 담당하는 mask 별로 일부 mask만 생성이 가능하다. vessel model |--------| A CT Image | | ---> | Model | ---> A mask P CT Image | | |________| ureter model |--------| | | D CT Image ---> | Model | ---> D mask | | |________| kidney/tumor model N CT Image |--------| N mask A CT Image | | A mask ---> | Model | ---> P CT Image | | P mask D CT Image |________| D mask 해당 과정을 수행하기 위해서는 우리는 각 Phase CT가 존재하는 경우, 향상된 알고리즘을 적용해 퀄리티가 좋은 결과를 존재하지 않는 경우, 퀄리티는 낮더라도 일반화가 잘된 기존의 모델을 활용하여 알고리즘 서비스 부분 백엔드 컨테이너를 구성해야한다. 기존의 백엔드와 결합을 위한 요구사항 image와 mask를 저장할 디렉토리의 절대경로가 함수의 입력값으로 주어질 것이다. 각 도커 컨테이너들은 공유된 하나의 볼륨을 마운트하여, 동일한 경로로 접근이 가능해야한다. 해당 알고리즘을 활용하여, 각 이미지 Phase에 해당하는 mask를 출력으로 줄 수 있어야 한다. 메모리 절약을 위해 인공지능이 필요한 정도의 spacing으로 이미지를 압축시켜 메모리 사용량을 줄여야한다. 따라서 아래와 같은 백엔드 컨테이너를 구성할 것이다. Step 0. 각 컨테이너는 gRPC를 통해서 파일 경로를 주고 받을 수 있어야한다. 그래서 예시 파일로 케이스 주소를 전달하는 Client Container, 해당 주소를 활용해 아래 Step을 실행하는 Server Container로 예시를 만든다. Step 1. 입력 폴더에 존재하는 이미지를 ai의 조건들을 분석하여, 그 중 가장 high resolution으로 resample해 임시로 저장한다.(모든 작업이 종료된 후 삭제 필요) Step 2. 아래의 조건에 따라 AI 알고리즘을 적용하여 결과값을 얻어낸다. Condition 1. A, P, D Phase가 존재할 때 1. A mask에 혈관, 종양, 신장 mask를 ai결과로 생성 2. D phase를 통해 생성된 요관 mask를 A phase로 옮겨 최종 결과 생성 3. 최종 mask를 각각의 N, P, D 이미지로 옮겨 각각 CT에서 각 기관의 대략적인 위치를 확인할 수 있게 생성 4. 각 Phase의 최종 마스크를 저장하고, 경로를 List로 저장해 반환 Condition 2. Missing Phase가 존재할 때 Condition 2-1. A or P Phase가 Missing Phase일 때 1. N, A, P, D의 신장, 혈관에 관련된 기존의 알고리즘을 적용한다.(Model 1) 2. obj를 만드는 이미지에 대한 prior를 기존의 내용을 활용한다. Condition 2-2. D Phase가 Missing Phase일 때 1. 요관 관련 모델을 활용하지 않는다. 해당 조건들에 따라 향상된 혈관을 RESAMPLE해 옮기던, 기존의 알고리즘으로 만든 것 + 요관 알고리즘 적용 여부를 최종 mask로 활용한다. 다만 Resample 적용 여부는 추후 필요성이 없어질 수도 있으므로, on/off가 가능하게 파라매터 입력을 받을 수 있게 한다. Step 3. 아래와 같은 입출력 구조를 가지도록 함수를 구성한다. input (case_directory : str, resample_condition : bool) 중간 과정 속에서 result_paths에 각 mask 결과물 실제 저장도 필요. output (result_paths : List[str])

Projects · 2025-07-09

프로젝트 개요

현재 ARNA 시스템의 문제점은 무엇인가 문제상황 회사 현재 ARNA 시스템은 각 nnUNet 기반의 인공지능 학습 결과를 여러 개 활용하고 이를 통합할 수 있는 기능은 구현된 상태이다. 이를 기반으로 ARNA 시스템은 FE와 통신을 수행하는 웹서버, 각 인공지능 pth파일을 갈아 끼우고 각 mask 결과를 통합하는 기능, 데이터베이스를 기반으로 의료진, 환자, CT 이미지, mask를 관리하는 기능 등은 이미 완성된 상태이다. 그리고 이를 monolothic하게 제작하였다. 그러나 시간이 지나며 다른 알고리즘 및 다양한 의료데이터를 활용하게 되며, 회사의 각 연구 주제들은 1. nnUNet 등의 ai를 학습시켜서 활용하는 프로젝트 2. shortest algorithm을 GPU에서 활용하여 독립적인 실행환경이 필요한 프로젝트 3. nii -> dcm 등 다양한 확장자를 가진 의료 이미지를 처리하기 위한 프로젝트 4. skeletonize, monopology 등의 다양한 컴퓨터 비전 알고리즘을 활용한 프로젝트 5. 완성된 segmentation mask의 결과를 3d object로 변환하고 이를 smoothing하는 프로젝트 등 각 프로젝트의 목적인 최적화, 데이터 변환, 인공지능 결과 생성 등에 따라 다양한 분야와 환경과 코드베이스가 쓰이는 상태이다.

Projects · 2025-07-08

1. 백엔드 구성 요소 정리

백엔드 구성요소에 대하여 현 진행상황 전체 백엔드 개요도 1. 백엔드가 연결된 대상 : FrontEnd, End Device 등등 해당 내용은 백엔드의 일부는 아니지만, 백엔드는 결국 End Device 및 Front End와 통신이 수행되야하므로, 해당 내용들이 어떠한 방식으로 통신을 주고받는지에 대한 고려가 필요하다. 2. 백엔드의 통신 구조 : API, Web Server API(Application Program Interface) : 백엔드끼리 혹은 프론트 엔드와 어떻게 통신을 수행할지 통신 구조에 대하여 설명 3. Logging Local Server log 혹은 전체 백엔드 시스템의 log를 모아서 관리하는 시스템 4. File Storage 5. Queue 6. DataBase 7. CI/CD 연구결과를 microservice로 통합하기 위해, 현재 제작중이 repogitory에서 기존의 연구 결과를 Docker를 통해 통합하여, 각 연구 결과가 Docker만 존재한다면 어느 환경에서든 실행되고, 이를 Docker Network로 통합하여 서로 간의 일반적인 통신(string, int, float, image 등)은 통신될 수 있도록 구현이 완료되었다. 이러한 프로젝트의 시스템을 monorepo로 만들어 아래 링크에 제작하였다. 문제상황 현재 이 작업을 수행하기 위한 연구원들의 가장 큰 문제점은 백엔드에 대한 전반적인 지식이 부족한 것이다. 개요에 존재하는 ARNA의 현 상황을 해결하기 위해 microservice + gRPC가 효과적인 해결책이 될 수 있겠다는 정보를 찾아냈으나, 이게 정말 최선의 선택인지에 관해 판단할 백엔드에 전반적인 지식을 가진 검토자가 존재하지 않는다. 이러한 문제를 해결하기 위해 백엔드에 대한 지식의 큰 줄기를 만들 필요성이 대두되었다 해결방안 이러한 회사의 제품이 앞으로 변경될 시스템에 따라 관리되야하고, 기본적으로 연구에 관련된 지식에 치중되어, Docker 등과 같은 배포를 위한 세팅이 대부분 수행되지 않은 연구의 결과물을 활용하기 위해서, 백엔드 시스템을 만들 필요성이 대두되었다. 그러나 현재 연구원들중 백엔드 지식을 폭넓게 알고 있는 능력을 가진 연구원은 없는 상태이며, 이러한 문제점을 해결하기 위해 백엔드를 구성하는 다양한 요소를 정리한다. 해당 요소 내에서 어떠한 구체적인 내용들이 있는지를 백엔드 개발자 로드맵을 통해 정리한다. 정리된 각 내용들의 장단점을 분석한다. 위 내용을 기반으로, 우리의 제품이 필요한 요구사항을 정리해보고 각 요소별 최적화, 하드웨어 요구사항, 보안 등의 요소를 고려해 어떤 요소에 어떠한 구성요소를 선택할지 결정한다. 위의 과정을 수행하여, 최적의 백엔드 시스템을 구성해보고 이를 유지/보수가 가능하게 만드는 것이 백엔드 서버를 구현하는 1차적인 목표이다. 이를 수행하기위해 Github Blog에 새로운 BE 탭을 만들어 전체적인 지식에 대해 정리해본다. 참고자료 코딩애플 : 마이크로서비스란 무엇인가 마이크로서비스의 구성요소 기술노트 : 백엔드 정리

Projects · 2025-07-08

1차 회의 - 방향성 결정

백엔드 서버를 어떻게 구성할 것인가? 현 진행상황 연구결과를 microservice로 통합하기 위해, 현재 제작중이 repogitory에서 기존의 연구 결과를 Docker를 통해 통합하여, 각 연구 결과가 Docker만 존재한다면 어느 환경에서든 실행되고, 이를 Docker Network로 통합하여 서로 간의 일반적인 통신(string, int, float, image 등)은 통신될 수 있도록 구현이 완료되었다. 이러한 프로젝트의 시스템을 monorepo로 만들어 아래 링크에 제작하였다. 문제상황 현재 이 작업을 수행하기 위한 연구원들의 가장 큰 문제점은 백엔드에 대한 전반적인 지식이 부족한 것이다. 개요에 존재하는 ARNA의 현 상황을 해결하기 위해 microservice + gRPC가 효과적인 해결책이 될 수 있겠다는 정보를 찾아냈으나, 이게 정말 최선의 선택인지에 관해 판단할 백엔드에 전반적인 지식을 가진 검토자가 존재하지 않는다. 이러한 문제를 해결하기 위해 백엔드에 대한 지식의 큰 줄기를 만들 필요성이 대두되었다 해결방안 이러한 회사의 제품이 앞으로 변경될 시스템에 따라 관리되야하고, 기본적으로 연구에 관련된 지식에 치중되어, Docker 등과 같은 배포를 위한 세팅이 대부분 수행되지 않은 연구의 결과물을 활용하기 위해서, 백엔드 시스템을 만들 필요성이 대두되었다. 그러나 현재 연구원들중 백엔드 지식을 폭넓게 알고 있는 능력을 가진 연구원은 없는 상태이며, 이러한 문제점을 해결하기 위해 백엔드를 구성하는 다양한 요소를 정리한다. 해당 요소 내에서 어떠한 구체적인 내용들이 있는지를 백엔드 개발자 로드맵을 통해 정리한다. 정리된 각 내용들의 장단점을 분석한다. 위 내용을 기반으로, 우리의 제품이 필요한 요구사항을 정리해보고 각 요소별 최적화, 하드웨어 요구사항, 보안 등의 요소를 고려해 어떤 요소에 어떠한 구성요소를 선택할지 결정한다. 위의 과정을 수행하여, 최적의 백엔드 시스템을 구성해보고 이를 유지/보수가 가능하게 만드는 것이 백엔드 서버를 구현하는 1차적인 목표이다. 이를 수행하기위해 Github Blog에 새로운 BE 탭을 만들어 전체적인 지식에 대해 정리해본다.

Projects · 2025-07-08

카페인 중독자

Contact

microservice project